实时数仓入门训练营：基于Hologres的实时数仓新架构

本文整理自直播《基于Hologres的实时数仓新架构》
视频链接:https://developer.aliyun.com/learning/course/807/detail/13890

典型业务场景列举

提到实时数仓，我们可以看一下数据业务典型的应用场景。

如上图所示，第一类场景是实时大屏。如今一般来说，不管是做to C还是to B的业务，或者说给上司看，都喜欢做一个业务大盘，来展现整个业务的运行情况。

第二类场景是BI报表，这类业务是从传统的离线BI报表产生的，只不过随着实时数据、实时业务的需求越来越旺盛，所以实时BI报表的需求也越来越多。

第三类场景是用户画像，不管是做金融还是做推荐，都是做千人千面，希望能够通过历史数据、用户行为数据得到用户的兴趣，来给用户提供更好的服务。

第四类场景是预警监控，或者说是流量监控。不管是做APP的还是做服务器端的监控，最终都是把数据收集上来，以这样大盘的形式进行展现。最终可以在这些预警指标进行报警，来保证监控业务的稳定性。

数据业务无论是离线还是实时，大致可以分为以上这么四类。

传统数据仓库数据处理流程

接下来我们看一下传统离线数仓是怎么样的一个处理流程。

上方是一个典型的传统离线数仓的数据处理链路。

首先，从业务系统CRM、ERP或者其他数据源把这些业务数据收集上来，然后经过离线数仓的ETL，然后对数据的话进行数据清洗、数据加工。在这个过程中涉及数据建模、数据分层，最终会把加工后的数据，或者是最终要产生BI报表的数据，通过BI工具或者写到数据库里面，推到一个在线系统里面去，最后提供给用户进行访问，这些用户可能包括产品的用户、运营同学或老板。

用户希望能够从这样的数据里面看到，比如整个产品的售卖情况，或者业绩的增长趋势，系统的一些指标等，这就是一个比较典型的离线数仓的处理流程。

批量数据分析流程有以下几个特点：

• T+1数据接入
  多种数据源接入
• 定时数据开发与应用
  1）数据提取/数据转换/数据加载
  2）ODS数据处理
  3）DWD标准数据场景
  4）MDM元数据
  5）数据集市应用
• 核心痛点
  1）ETL计算/存储/时间成本过高
  2）数据处理链路过长
  3）无法支持实时/近实时数据分析

Lambda：割裂的架构，需要变革

为了解决传统数仓的问题，出现了一些新的解决思路。

首先在2011年之后兴起了Lambda架构，如上图所示。

Lambda的大致思路还是以传统的离线数仓为主，然后引入了实时数据的处理链路。T+1数据还是走传统离线数仓链路，然后再加上一个实时的数据链路，再把这些实时数据和离线数据汇总到一起，然后再通过一个Merge层提供数据服务，对外提供的服务可能是点查询，也可能是做复杂分析，还有可能是做联邦查询。然后在这上面去加数据应用，比如上文提到的BI报表，实时大屏，用户画像等。

从架构的名称Lambda就能够看出来，其实它是在传统离线数仓基础上加了实时，解决传统离线数仓的问题。但其实整个Lambda架构也有一些问题，主要存在的问题是架构复杂、数据同步难、资源消耗大、数据孤岛、人才培养难、开发成本高、不敏捷。

比如，Lambda架构并没有从源头上解决传统离线数仓的问题，而是在传统离线数仓上加了一条链路，这会让整个系统变得更加复杂。

在架构复杂的基础上，数据可能会存两份或者存多份，实时链路和离线链路数据不统一。除此之外，整个架构维护起来也是非常复杂的，并且开发成本比较高。比如说离线链路用Spark或者Hive，实时用Flink，但其实这些SQL是不太一样的。还有元数据如何管理，数据如何治理，再加上提供服务的时候，Merge层可以用HBase、Redis这样的系统去做，这些API其实都是非常复杂的。对一个小企业，做这种数据开发或者说做这种数据平台，资源是有限的，学习成本非常高的。经常发生的情况是，小公司刚把一批同学培养起来能够熟悉这些系统，然后就被其他公司挖走了，因此人才成本也非常高。

阿里巴巴的整个数据业务也是沿着这条路走过来的，我们思考有没有什么方法来简化这个架构，下面来看一下。

首先一个简单的思路，就是能不能把离线数据和实时数据进行统一。我们首先做的事情是实时/离线一体化，把实时ETL和离线ETL进行统一，整个数据模型进行统一。

在实时/离线一体化的基础上，分析部分是偏离线的，服务部分是偏在线的，我们思考能否把这两部分也做一个统一，让一份数据既服务于离线又服务于在线。我们把这样的架构叫做分析服务一体化，分析相当于离线分析，服务是提供在线服务。如果真能做到一体化的话，相当于是由传统的OLAP变成了分析服务一体化架构。

思路有了，接下来我们看一下怎么去做这个事情。

阿里业务场景原架构

阿里巴巴原来的业务也是由传统Lambda架构走过来的，下面介绍阿里巴巴一个业务场景：搜索推荐场景。

如上图所示，最早的时候这个架构就是为了解决实时推荐。大家都清楚阿里巴巴最主要的是电商业务，电商业务以淘宝为核心，打开淘宝会给用户推荐很多内容，其实这些推荐的内容都是一些行为事件，包括在滚屏看到的那些内容都是一条条事件。这些事件会实时写到后台服务里面，然后经过Flink做实时ETL，做实时的模型训练，或者做数据采样，会把这些数据写到HBase或Cassandra里面。

通过在HBase里面做实时的模型训练，再把这些模型推到搜索引擎或者在线服务里面，这样的话就能够完成实时推荐的链路闭环，能够提供点查询的数据服务。

那么我们想对已经存在的数据样本或者数据特征进行分析怎么办？我们引入列式查询的产品，比如ClickHouse或者Druid做分析，然后去接一些报表。如果还需要做数据的离线归档怎么办？可以通过MaxComputer或者Hive去做离线归档。有了实时数据和离线数据，那么就要去做离线/实时的联邦分析，又引入Drill和Presto。我们都清楚，像Drill和Presto这样的系统的话，它整个的性能或者QPS承载的并发非常差的，如果想提高并发怎么办？我们引入了Redis和MySQL去做这样的一个Cache，然后通过非常短周期的调度，从 Drill和Presto去做查询，再把结果写到Redis或MySQL里面去，然后整个数据去对接API服务或者对接报表等。

上方就是阿里巴巴搜索推荐场景原来的业务架构，是一个典型的Lambda架构。绝大部分公司从业务出发的话，也是这么一个架构。

下一代实时数仓如何选型

按照上文的思路，如果我们想去简化这样的架构，把实时/离线一体化，再把分析服务一体化，我们需要一个新的实时数仓，应该怎么去做，考虑哪些问题？

首先，必须支持实时写入，传统离线T+1肯定是不可以的。除此之外，能够支持非常实时的计算。

第二是能够把实时数据和离线数据存放在一起，做到实时/离线数据一体化，减少数据的移动。

第三是希望平台跟上层的业务能够解耦，意味着平台必须具备一定的通用性，而不是一个定制的产品。

第四是对于上层业务使用的API，我们希望能够拥抱开源生态，并且希望整个系统或者产品是一种云原生的架构，便于云上用户使用。

为了解决上述问题，我们从已有的一些开源产品里面找找灵感，看看它们现在是怎么去做的，每个产品解决哪些问题。

如上所示，首先一大类是数据库产品，如MySQL、PostgreSQL等，它们比较典型的是支持事务，事务最重要的是支持ACID，做到读写一致性，保证数据的一致性。但是它们有个缺点，就是Scalability往往很难做到PB级别，同时不能做非常复杂的Query分析。

第二类是现在面向于分析加速或者OLAP这样的系统，比较典型有Presto，ClickHouse，Hive等，这类的特点是大规模数据扫描、过滤、汇总，语义层，分布式，列式存储，面向分析师。

第三类是Serving场景，提供高并发，支持简单快速的查询，比如Cassandra、HBase、Redis等，能够提供非常高的性能。

目前有一种趋势是很多产品在做HTAP，就是把Transaction和Analytics融合，相当于在一个产品里满足这两部分能力，目前有很多产品在一定程度上都能做到，其中有一些隔离性或者数据一致性的问题，但是基本是可解的。这类场景的话往往是Transaction，以TP为主业务基础，然后在TP数据的基础上做一定的分析。针对这种场景，我们对读写一致性没有很高的要求，只要做到最终一致性就好了，更多的是要求能够支持非常高并发的查询和分析。把这两类场景结合到一起的话，我们叫做Hybrid Serving/Analytics Processing（HSAP）。

目前在市场上并没有这样一类产品，我们希望做出这样的产品来解决分析服务一体化。有了架构理念，下面我们看一下如何实现。

新一代技术理念HSAP：分析、服务一体化

Hybrid Serving/Analytical Processing

我们首先想到是做统一存储，把离线数据和实时数据放到一起做规划处理，然后对统一存储的数据提供统一的数据服务，上层的数据应用如数据报告、数据看板、在线应用等，都直接通过在线的数据服务，提供统一查询出口，就可以解决上文的问题。

有了这样的思路后，我们研发了一个产品——Hologres。

简单介绍一下Hologres这个产品的名字是怎么来的，它是由两个单词拼成的，一个是Holographic，另一个是Postgres。

Postgres代表PostgresSQL的生态，Holographic来源于物理学。

我们知道，黑洞连光都能够吸进去，但是我们在地球上并没有被黑洞吸进去，是因为我们离这个黑洞足够远，这是否就意味着有这一个临界点，这个临界点之内的都会被黑洞吸进去，临界点之外的能够逃出黑洞引力。

由这个临界点组成的一个面，被证明是个球面，我们把它叫做世界面。有科学家证明黑洞里面的所有信息在世界面上都有投影，意味世界面上包含黑洞的全部信息，也就我们经常提到的3D全息投影技术，全息的英文单词就是Holographic。

Hologres想做的事情是通过产品对数据黑洞做全息展示，全部信息在Hologre能够提供服务的能力，并且数据存在Hologres的数据黑洞里面。

阿里搜索推荐：从N到1，Hologres简化大数据架构

上图为使用Hologres前后的架构对比图，使用了Hologres之后整个架构就变得非常简单了。

首先，Flink实时写入到Hologres里面，也可以通过Hologres做维表关联。同时，通过实时数据可以归档到MaxCompute里面。这样的架构对于数据服务来说非常简单，离线分析走MaxCompute，数据的点查询、离线加速、联邦分析或交互式分析等可以走Hologres。

整个阿里巴巴的业务架构由左边演变成右边，带来的收益是业务敏捷响应，数据自助分析，避免数据割裂，赋能数据服务，简化运维管理。

下面我们来简单看一下Hologres到底是个什么样的产品。

• Hologres = Better OLAP + Better Serving + Cost Reduced

Hologres基于HSAP理念，云原生分布式分析引擎，支持对PB级数据进行高并发、低延时的分析，支持实时数仓，大数据交互式分析等场景。

Hologres的特点是提供分析服务一体化，如点查询景，类HBase、Redis场景。OLAP场景能够提供PB级别复杂查询，毫秒级交互式分析。Hologres以实时为中心设计理念，查询快，实时数据写入快，并且能够支持实时数据、离线数据的快速导入。整个架构是存储计算分离的架构，在云上面跟MaxCompute无缝打通，并且从Hologres这个名字就能看出来，Hologres兼容PG语法，支持PG开发运维工具。

如上图所示，Hologres是典型的存储计算分离架构，整个数据是在一个共享存储里面，这个共享存储可以是阿里云内部的存储产品盘古，也可以是数据湖的产品，比如OSS、Hive或者MaxCompute这样的存储。

计算节点都是在容器里面，提供一个Worker，还有一个角色是Frontend，相当于是能够接收用户的SQL。接收完SQL以后进行SQL解析生成AST，然后通过优化器把AST转化成分布式的执行计划，通过Coordinator发给这些Worker去做，每个Worker里面有自己的调度系统，有数据的分片管理，同时还有Cache，然后能够分步式执行。整个计算节点是MPP架构，然后是存储计算分离的。

存储计算分离

下面我们看一下存储计算分离能带来的好处。

一般来说，现在的大数据产品或者数据库产品，存储计算就几种关系。

第一类是传统Oracle的RAC，它们是Shared Disk/Storage的架构，相当于有单独的计算节点，每个计算节点有自己的本地盘，有自己的内存，然后还有一个存储集群。存储集群相当于是一个管理的磁盘阵列，这些盘对这些节点都是开放的，这些节点能够直接访问存储的数据。

第二类架构是Shared Nothing，开源系统用得比较多的像Clickhouse或者Druid，特点是存储节点不共享。存储节点和计算节点绑定，相当于每个计算节点有自己的一块存储。如果其他的计算节点想读另外节点的存储，必须通过网络请求到计算节点，然后通过计算节点再把这个数据给另外的节点。

这个架构带来的问题是很容易产生数据热点，比如Node2，假如它数据特别多，这个数据也没办法存到其他节点上，这样的架构往往会使整个Scalability受限。

第三类是云原生这种完全存储计算分离的架构，计算节点部署在容器里面或者是单独的服务器ECS，存储是以共享的存储服务或者DFS的方式进行访问。整个架构非常清晰，对于计算节点来说，看到的就是一个非常大的分布式文件系统，计算节点只需要关心到底要访问哪个文件，而不需要知道这个文件到底在哪存的，容错怎么去做。

Hologres就是采用这样的计算存储分离架构，架构带来的好处是可以按需购买，在云上面需要多少计算就买多少计算资源，需要多少存储就买多少存储资源。

流批统一的存储

有了分析服务一体化的架构，就能把流计算和批计算的结果进行统一。

以前流计算产生的结果写到流计算存储，离线计算的结果写到离线计算存储，引入了Hologres以后，相当于不管是离线计算还是流计算，都写到Hologres里面来，数据的一致性能够得以保证。

Hologres支持点查询、分析型查询，主要是因为Hologres的存储引擎支持两种文件格式，一种是行存，一种列存。顾名思义，行存就是同一行数据的多个列是连续存放在一起的。如图所示，列存就是相同列存放在一起，带来的好处就是在分析的时候能够提高Cache命中率，并且可以用向量计算做一些加速查询。

整个Hologres存储引擎的架构是类似于LSM-tree架构，数据先写MemTable，写满以后Flush成文件，小文件太多的话合并成大文件然后做管理。

Hologres：为分析服务一体化设计的实时数仓

Hologres的宗旨是做分析服务一体化的实时数仓，简单总结有以下三方面的特点：

• 云原生：存储计算分离架构

1. 计算存储资源弹性扩展，按需使用；
2. 低成本、高可用、高可靠；
3. 与MaxCompute底层打通，透明加速，实时离线一体。

• 统一存储：流批统一的存储

1. 行列共存，列存对分析友好，行存对点查快速；
2. 高效数据分片、分段、压缩、索引；
3. LSM-like写友好数据结构，高吞吐数据写入，支持更新，写入即可见。

• 极致性能：C++ Native执行，引擎+优化器

1. 向量化、全异步等执行引擎优化；
2. 轻量级用户态线程调度，同时支持多种查询负载（高并发、复杂统计）；
3. 公平调度算法（CFS），高并发充分利用计算资源。

交互式分析典型应用场景

由于Hologres架构非常简单，因此典型的应用场景也就非常简单，大致可以分为以下三类。

第一类是替代传统的离线数据做加速查询，可以把传统的离线数据导到Hologres里面来，这样的话就能够变得很快。

第二类是做实时数仓，跟Flink进行配合，把实时的ETL实时数据加工写到Hologres里面，然后在Hologres做实时的数据分析。

第三类是把实时离线一体化，能够把实时/离线数据都写到Hologres，甚至可以通Hologres做联邦查询，直接对其他系统的数据进行查询。

下面举几个业务场景的例子。

阿里客户体验系统(CCO)实时数仓改造

2020双十一活动期间，实时计算 Flink 版 + Hologres为阿里客户体验系统(CCO)构建了集实时化、自动化、系统化于一体的用户体验实时数仓。

以前的阿里客户体验系统(CCO)也是典型的Lambda架构，存储层有MySQL，HBase等，只用Holo去存这种Server数据。

架构升级主要有以下几个业务难点：
1）数据复杂度高，加购、下单、支付、售后全渠道，90%实时数据；
2）数据量大，日志（千万/秒)，交易（百万/秒)，咨询(万/秒)；
3）场景丰富，实时监控大屏，实时交互式分析数据产品，ToC线上应用。

升级后的架构如下所示。

带来收益:
1）整体硬件资源成本下降30+%；
2）高吞吐实时写入：支持了行存千万/秒，列存几十万/秒写入要求；
3）简化实时链路：面向公共层的开发和复用；
4）统一服务：同时支撑了多维分析和高QPS服务化查询场景；
5）MC-Hologres查询服务：2020双11当天查询latency平均142ms，99.99% 的查询在200ms以内；
6）支撑200+实时数据大屏搭建，为近300+小二提供稳定的数据查询服务。

菜鸟：智能物流

菜鸟智能物流分析引擎是基于搜索架构建设的物流查询平台，日均处理包裹事件几十亿，承载了菜鸟物流数据的大部分处理任务。

需求诉求：
1）HBase的架构下维表数据导入耗时长、资源浪 费严重、成本高；
2）HBase不能同时满足PointQuery和OLAP分析，数据导入导出引发数据孤岛、数据同步负担、冗余存储、运维成本和数据不一致等问题。

升级后的架构

升级架构后的客户收益：
1）整体硬件资源成本下降60%+；
2）更快的全链路处理速度（2亿记录端到端3分钟）；
3）一个系统，满KV和OLAP两个场景，没有数据冗余；
4）解决大维表实时SQL查询需求；
5）强Schema，有效避免潜在错误，节省时间。

友盟+：PB级用户行为交互式分析

友盟+是国内最大的移动应用统计服务商，其统计分析产品U-App&U-Mini & U-Web为开发者提供基本报表统计及自定义用户行为分析服务，支持精细化运营。

业务痛点：
1）业务数据量大，年新增行为数据10PB级，个性化、自定义地交互式用户行为分析强需求；
2）基于MaxCompute提供异步离线的adhoc分析和优化、以及自研引擎开发尝试均无法满足业务需求；
3）导出到MySQL/Hbase方案的二次开发和数据导出链路长、成本高、操作不灵活。

升级后的架构

客户收益：
1）PB级数据毫秒级查询响应；
2）与MaxCompute深度集成，能够利用Range Cluster索引加速，实时离线联邦查询，同时也可以实现冷热数据混合查询，有利于成本性能平衡；
3）计算资源弹性伸缩，可兼顾扩展性、稳定性、性能、成本。

实时推荐、API as service

实时推荐（特征查询、实时指标计算、 向量检索召回），提高广告留存率， 实时计算 Flink 版+PAI+Hologres with Proxima。

客户收益：
1）支持2000万日活用户快速向量检索，千万级u2u,i2i 均可以20ms返回 ；
2）通过SQL描述业务逻辑，无需手工编码(select a, b, proxima_distance(c) as distance from table order by distance desc limit k;)；
3）加工逻辑简化，无需额外集群（Redis）。

活动推荐

阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：
99元试用实时计算Flink版(包年包月、10CU）即有机会获得 Flink 独家定制T恤；另包3个月及以上还有85折优惠！
了解活动详情：https://www.aliyun.com/product/bigdata/sc